The default install of aptosid (formerly sidux) maps the windows key to compose (Multi_Key), which is used for entering special characters with key combinations. This drives me nuts, because (a) I use the windows key as a modifier for launching my most common applications and (b) I never need to enter the special characters. Today I finally figured out why this is happening, and how to resolve it properly without an xmodmap band-aid.
Looking in /var/log/Xorg.0.log, I noticed this:
Option "xkb_options" "lv3:ralt_switch,compose:lwin"
Turns out this can be changed by running dpkg-reconfigure keyboard-configuration or by editing /etc/default/keyboard manually, and then restarting the entire system. That’s right, restarting hal and X, as suggested in the config file, was not enough. Makes me feel nostalgic for windows…
The problem with using xmodmap is that if the keyboard is hotplugged, the settings are lost. It’s also a pain to get xmodmap to run consistently when X starts across all login managers and manual startx. However because of the bizarre restart requirement, it may be useful. The keycode can be determed by running xev and pressing the windows key; mine was 133. Then run xmodmap:
xmodmap -e 'keycode 133 = Super_L'
This issue seems like a bug in the aptosid installer (or maybe the debian packages); if a user chooses US american keyboard layout, it’s very unlikely that they will use the compose key. At the very least the user should be prompted for this during install.
Much appreciated, my friend! I usually change KRun in KDE to Windows+Space, since I used Gnome-do in Gnome for many years that had that particular key-binding. I was a bit surprised when I went to changed it in aptosid and it did not work as I was expecting.
Thanks so much for this! I was convinced none of my openbox keyboard shortcuts were working in aptosid (no google results), then narrowed it down to just the windows key, and found your solution.
You’re right – this is a bug.